Electronic devices, such as mobile phones and personal digital assistants (PDA's), often contain firmware and application software that are either provided by the manufacturers of the electronic devices, by telecommunication carriers, or by third parties. If firmware or firmware components are to be changed in electronic devices, it is often very tricky to update the firmware components.
It is often difficult to determine what is wrong with a device when a problem is encountered. Quite often, a customer care representative for an operator does not have answers to a customer's problem and is not able to fix it. Determination of problems with a customer's mobile device is a big problem for operators. Answering customer care calls is quite expensive. Especially so if at the end of such a call, the customer care representative is unable to determine what is wrong with the device.
Different devices have different set of resources, different sets of parameters, etc. Managing mobile devices in a heterogeneous network is a huge problem. Figuring out what parameters need to be set is also a problem.
Customer care centers get numerous calls for support from customers. They have very few means to determine what is wrong with a device. The Customer Care Representative (CCR) often asks questions of a customer, but they do not get proper answers. Customers often do not know what is wrong with their device. Thus, configuration changes that can fix a problem cannot be easily determined. Again, firmware updates that can fix the problem cannot be identified.
Quite often, even when a problem is diagnosed, a solution may not be available. Thus, customers who call to report a problem go away without having solved it.
If an operator needs to update millions of phones to fix a known bug, it will be very expensive and take a lot of resources. There is no easy way to conduct mass updates of millions of devices, such as mobile handsets.
The Open Mobile Alliance (OMA) device management (DM) protocol is emerging as the principal protocol for managing handsets over the air (OTA). Unlike earlier “push” based protocols, the OMA DM protocol allows a rich dialog for the exchange of information and commands between an OMA DM-capable handset and an authorized, OMA DM-capable management server. The OMA Download (DL) OTA protocol is still the preferred protocol for performing the download of application and firmware content, but the overall management of such operations can now be initiated and managed using the OMA DM protocol.
OMA DM protocol management operations may be controlled through the use of management objects, abstracted as a hierarchical tree structure. The management tree provides a common language between the client (an electronic device such as a cellular phone, pager, or personal digital assistant, for example) and the server (e.g., a device management server) for information exchange, expressed in terms of management objects. Each management object represents one or more data values that can be exchanged between the client (e.g., the electronic device) and the server (e.g., a DM server) using the OMA DM protocol. In addition, each management object may also have its own unique “behavior” which can be triggered by any OMA DM command deemed suitable for that purpose.
Unfortunately, OMA DM has yet to define OMA DM objects for many of the values and operations required to achieve the level of comprehensive device management presented in this requirements specification.
Further limitations and disadvantages of conventional and traditional approaches will become apparent to one of skill in the art, through comparison of such systems with the present invention as set forth in the remainder of the present application with reference to the drawings.